1. Field of the Invention
The present invention relates generally to World Wide Web servers and, more particularly, to techniques for replicating state among World Wide Web servers.
2. Related Art
Current World Wide Web servers (“Web servers”) are accessed by client computers using the Hypertext Transfer Protocol (HTTP) or its encrypted form (HTTPS). A typical interaction between the client computer and a Web server consists of several HTTP and/or HTTPS requests. For example, when a user of the client computer first accesses a Web site via a Web browser, an HTTP connection request is sent to a Web server maintaining the Web site. The HTTP request contains a Uniform Resource Identifier (URI) which specifies the Web page being requested. The Web server, in turn, responds to the HTTP request by downloading the requested Web page (e.g., a Hypertext Markup Language (HTML) file) to the client computer. The Web page is then interpreted by the Web browser executing on the client computer and displayed to the user. If the user selects a hyperlink on the Web page, a new HTTP/HTTPS request is sent to the Web server, which may result in a new Web page being downloaded to the client computer.
Since the HTTP/HTTPS protocols are inherently stateless (namely, an HTTP/HTTPS request intrinsically contains no information about the outcome of a prior request), a Web server communicating with a client computer cannot rely on these protocols for maintaining state (i.e., storing information about the stage of processing of the client computer's overall interaction with the server). The series of discrete HTTP/HTTPS transactions over which state is maintained is typically referred to as a “session.” As the amount of state data to be maintained increases, or sensitive information is included among it, techniques for exchanging the state data explicitly across HTTP/HTTPS become unsuitable and the state data must be maintained locally on the Web server or some other computer (e.g., a database server) to which the Web server has direct access. Instead of transferring a large amount of sensitive state data, a small token uniquely referencing the state data is exchanged by the client and server across HTTP/HTTPS, while the state data itself is kept on the server. This general architecture is referred to as “server-side state,” and the reference token as a “session ID.” Server computers in this architecture are thus referred to as “stateful.”
As the number of users increases, a typical Web site cannot handle all users' requests using a single server, but rather has to employ a pool of servers to handle user requests. FIG. 1A illustrates a client 110 and a pool of Web servers 120n (where n=A, B, C, . . . ) connected by a computer network 130. If state is maintained during a session, either the client must always connect to the same server during the session, or state must be shared among all servers in the pool. When state is maintained server-side, this presents the problem of replicating state information throughout the servers in the pool. Servers that replicate server-side state data in this fashion are referred to as “collaborating” servers.
In some cases, all of the collaborating Web servers 120n of FIG. 1A provide the same set of services redundantly (where the redundancy is purely for purposes of accommodating large numbers of users). For example, servers 120n might all provide a company's online product support services. In other cases, however, it is advantageous to replicate server-side state among servers providing different sets of services to the same users. For example, servers 120A and 120B might redundantly provide a company's online product support services, while server 120C might provide the company's online product catalog, and server 120D might provide the company's online product store.
Furthermore, in the case where servers 120n provide different services, the state data being replicated might constitute all of the data tracked for a user or session by each service. But in other cases, just a common subset of the state data might need to be replicated. Indeed, in some of these cases, there might be multiple such subsets, each needing to be shared and hence replicated independently among particular services. To build on the prior example, only servers 120A and 120B (the product support service) and server 120D (the product ordering store) might share product order history data. Only servers 120D and 120C (the online catalog) in turn might share product preference data. And all four servers might share user registration data.
Thus replicating one or more server-side state objects across one or more (possibly heterogeneous) Web server collaboration pools becomes necessary to share the appropriate sets of state data among the appropriate Web services. Typical prior art collaborating Web servers (e.g., collaborating Web server 120A) would share state data by broadcasting any changes in the state data to all other collaborating Web servers (e.g., collaborating Web servers 120B, 120C and 120D), as shown in FIG. 1B. While this approach works satisfactorily when the number of collaborating Web servers is small, it becomes increasingly more impractical when the number of collaborating Web servers and/or the amount of state data shared among the collaborating Web servers grows. As a result, there is a need for an improved system for replicating server-side state amongst stateful Web servers that overcomes these limitations.